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Multics altows objects in its storage system nierarchy 
to be referencea by three distinct classes of names? path names, 
reference names, and segment numbers. The binding of these names 
to objects in the hlerarchy is controlled by directory control, 
name space control, and address space control! respectively. 
Currently the modules [In the hardcore supervisor that implement 
these functions are. more interconnected than need be. This MTB 
proposes a restructuring of address and name space contro! which 
alltows name space control to be removed from the security kernel 
of Multics. Together with Phil Jansons previously completed 
userering linker , this design produces a simpler, smalter 
supervisor with a simpler interface. 


Currentiy a@ process*® name space has two distinct 
components: a Segment name space and a directory name space. The 
segment name space associates names with non-cirectory segments. 
This name space is under explicit user control. That is, the 
process is free to associate any name or group of names with a 
segment. Furthermore, a process may dynamically modify its 
segment name space. The directory name space which associates 
names with directory segments, however, is not subject to 
exolicit user control. Instead, it is managed by ring zero which 
constrains names of directories to be absolute pathnames of the 
directory. 


The aistinction between segment reference names and 
directory reference names seems somewhat artifical. A process 
Shou!ta be free to associate any name it chooses with a directory. | 
Consider how easily the working directory and search directory 
concepts fit Into such a scheme. We could bind the name 
“working _dir” to a process*® working directory and “search_dir_n”™ 
to its n*th search directory. A process coutd then reference 
these directories by name using The normal name space management 
mechaniSmss 


The primary goal of the design presented in this MTB is 
to remove name space management from the security kernel of 
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Multics. It has been argued that a serious consequence of any 
scheme which realizes this goal is that a process* name space can 


no longer reflect name changes in the hlerarchy. This argument 
is basea on a confusion between reference names and directory 
entry names. Ij seems oOVioUS That a Brocess does not w#ant its 


name space to change without Its consent. Changing a segments 
name does not change a process* access to ite A prime advantage 
of reference names is precisely this ability to insulate a 
process from name changes in the hlerarchye We should 
distinguish reference names from dairectory entry names. A 
reference name is a name we temporarily bind to a segment. A 
directory entry name is a selector of a particular entry in a 
directory. We neec directory entry names oniy to physically 
select a branch for the first time$ after that we shouid be free 
to call it whatever we choose. If any valid reason exists’ for 
notifing a process that the names on 8 segment or directory that 
it is using have changed the System could signal a 
name_change_on  segment_x condition. This would require the 
addition of some sort of KST traiter mechanism to the system. 
This may eventually be necessary if for no other reason than 
Multics will eventually run for extremely long uninterupted 
stretches. If a orocess were to stay permanentiy toggea in it 
would require notification of one-line installations. This in 
Itself is sa difficult problem which I do not intend to address 
here. The only point I wish to make is that the process and not 
the system should contro! the duration of name bindings. 


While there does not appear to be any Intrinsic need 
for the Multics security kernel to Support name space management, 
its removal from ring zero is complicated by the fact that the 
current Multics  adcress space manager, which provides a 
legitimate kernel function, depends on the name space manager. 
Specificaily, the address space manager uses’ the name space 
maneger to manage an assoclative memory of (directory pathname, 
Segment number) pairs. It is therefore necessary to decoupie 
address space management from name space management oboefore the 
latter can be removed from ring zero. 


The dependence of address space control on name space 
control manifests itself in the recursive procecure find. «hich 
the adecress space manager uses to map directory pathnames into 
directory segment numbers. When find. Is Invoked It calis the 
name space manager with the pathname it is givene If the name 
space manager returns a segment number then find. is done. 
Otherwise, find. splits the pathname into a pathname of the 
parent clrectory of the target alrectory and the name of the 
target directory. It then calls itself recursively to obtain a 
seament number for the parent directory. Using this segment 
number as ae pointer to the parent directory, fino. attempts to 
initiate the target directory. If it suceeds it adds the pair 
(path name of targets, segment number of target} to the name space 
manager“*s data base and returns. 


This proposal suggests a radical change in the ring 
zero adcress space manager. The essential result of this change 
is that find_, as described above, need no tlonger be called by 
the address space manager. This allows both find_ and name space 
managenent te be removed from ring zero. 


Currently, determining whether a process should be 
permitted to initiate an arbltrary directory is quite difficult 
since we wish fo prevent a process from detecting whether or not 
a given directory exists unless If has access to that directory. 
This difficuity stems from the fact that the ACL of a branch and 
its physical storage map reside in its parent. Since we wish the 
ACL of a branch to exercise complete control over access to that 
coranch, we must permit a process to initiate ali superiors of 
accessible segments independent of access to these superiors! To 
avoid this difficulty, Multics Inexorably couples the initiation 
of a directory with Initiating an Inferior segment. This 
inability to initiate directories directiy thas lead to many 
neediessiy complex mechanisms for manipulating dlrectories. In 
addition it has forced us atways to refer to directories by 
pathname. Not only is this inefficient, but it requires that the 
address space manager be abie to call find_. If we could 
Initiate directories directiy then we could use segment numbers 
as directory specifiers. Address space contro! could then take a 
segment number Instead of taking a pathname as a directory 
specifier. Since address space contro! would no longer need to 
cal find. it could move out of ring zero along with name space 
management without compromising the security of address space 
contro!. 


Actualtiy, coupling directory and segment initiation 
does not solve the problem. Since a process cannot read _ the 
access control fist of a segment until its parent is known, the 
system stilt must permit a process to initiate directories which 
lt may not have the right to know exist! By causing the 
initiation of these superior directories to occur in a single, 
indivisabilie ring zero calls the system could, in principle, 
prevent security teaks. This could be accompoptished by terminating 
those intermediate directories which had to be initiated only to 
find that the process had no access to the terminal segment, 
before returning to the caller. Unfortunately, the current system 
does not do so. This ailows any process to determine the 
existence of any postulated directory. Certainly one approach is 
to correct this flaw in the current system. However, there seem 
to be many ways of forcing such a scheme to compromise 
Information. For example, suppose 383 process filfted up Its 
aadress space intentionality and then called ring zero to initiate 
>secret>x. If ering zero was not very careful if might cause the 
process to die due to a KST overflow if and onty tif >secreft 
existea. This would alftow the existence of >secretf to be inferred 
by whether or not the process died. 


I propose that we decouple segment and directory 


initiation. As was noted earlier tne basic problem to be solved 
is how can the system decide whether a process should be allowed 
to initiate a given directory. There are essentiatiy four 
schemes for making this decision. The first scheme invoives 
recognizing that if tne access controi fist of 4a agirectory is ts 
comoletely express access fo that directory we must make explicit 
the now “nidden™ permission to initiate a directory if some 
descendent of the directory is accessibie to the process. The 
obvlous way to accomplish this is to Invent a new directory 
access mode called “initiate". Tnis mode altows the named 
principal to initiate a directory and to use the information It 
conteins which Is relevent to accessing descendents of that 
directory. This makes the decision of whether or not a process 
shoutd be altioned to Initiate a directory quite simple. If the 


process has non-enul! access to fhe airectory fhen It may initiate 
it. Otherwise, it may note Unfortunately, tnis scheme defeats 
our desire to nave the access control list of a segment or 


directory compietely express what processes may access tnaft 
segment or directory. 


A second way to decide whether a process may Initiate a 
directory is to search the hlerarchy subdtree rooted at that 


directory. If the process has non-null access to any member of 
this subtree then the process shoula be aliowed to Initiate the 
directory in aquestion. Naturatily, this scheme is far too 


inefficient to consider serlousty. 


A third method of cdecialng whether 2a process may 
initiate a directory is to require non-nuli access to the 
dlrectory. This scheme has the disadvantage, shares by the first 
scheme discussed, of preventing the access control fist of a 
directory or segment from being the sole arbiter of access to 
that clrectory or segment. Inorder to initiate a segment a 
process would need nonenulli access to the superiors of that 
segment. 


I propose that we take a forth approach to the problem 
of initiating directories. Instead of worrying about whether or 
not a process has the right to initiate a directory tet us aiiow 
allo processes to initiate any directory =< whether or not it 
exists! The key to this scheme is preventing the user § from 
detecting any difference between an initiated dalrectory which 
does not exist and an initiated directory which exists but which 
the user nas not proven his right to know exists. How this Is to 
be cone will be discussed later. The ring zero adaress space 
manager interface resulting from this approach seems quite 
naturai. Ring zero no tonger concerns itself with pathnames. 
Instead, it accepts airectory segment numbers for directory 
specifiers. To allow tnis scheme to bootstrap itself we willl 
define the segment number of the parent of the root to be zero. 
Initiation of segments anc directories witli be controtited by 
initiate. which wiitt accept a parameter specifing whether a 
segment or directory Is to be initited. The rationate pbenind 


distinguishing directory and segment initiation is that a process 
usually has a preconceived idea about the type of a branch it 
wishes to initiate. When reatity does not support this 
preconcelved idea the process is usually in error. Forcing the 
process to fake expticit the type of branch if is expecting 
altows ring zero to Immealately catch ali such errors. Tnis 
prevents a careless process from bumbling along thinking alt is 
well only to die when if attempts to access a directory as a 
segment or vice versae 


An important consequence of not handling pathnames in 
ring zero is that file system Jinks can no longer be interpreted 
in ring zero. This requires thaf links be readable in tne outer 
rings which raises the question of what, if any, access control 
shoulta be placed on reading tinkse The simple approach, which is 
taken in the current system, is to make links completely pubdlic, 
readable In all rings by ail processese This nas the disadvantage 
that if some process can guess the pathname of a real link then 
it can prove the existence of the parent directories of that 
tink. Af the other end of the specfrum we could place access 
control tists on iilnks thereby explicifly naming those processes 
which may read the link. This seems a bit too bulky. I propose 
that we consider a tink to be part of its containing directory, 
readable only by processes having status permission on that 
directory. This scheme has the virtues of being simple, easy to 
implement, and plugging the information hole which uncontrolled 
access to tinks provides in the current system. While tnis scheme 
does make one class of currently legal uses of tinks illegal, 
this restriction does not seem Too severe. 


When initiate. encounters a fink it will return the 
J}ink and a status code which informs the outer ring procedure 
that a tink was encounterea. The oufer ring procedure may then 
try fhe new path specified by the tink. Since this is happening 
in an outer ring we need no tonger have a standard interpretation 
of tinkse That is unless the function moves out of the kernel but 
not out of the supervisor. If snowever, it resides in the user 
ring the process may interpret tinks In any manner it chooses. 
Why not let tinks contain retative pathnames ,offsetSs or even 
arbitrary character strings? The important point is that while 
the kernel may be the keeper of tinks it does not Interpret them. 
Naturaltiy the restriction on tink depth, which was intended to 
keep ring zero from getting into trouble, vanishes. 


We can use this same mechanism of refiecting 
information out to an outer ring by setting a status code to 
indicate the fact that a segment*s copy switch was sete This 
aliows the concept of a copy switch to move out of ring zero. 
Whether it is still handied within the supervisor buf in a higher 
ring or within the user‘s ring depends on whether it is to be 
considered a basic, unchangable system function or not. 
Personally I would move if to the user ring! 


To complete our new ring zero address space manager 
interface we must introduce a terminate primitive. This 
primitive accepts three arguments. The first argument specifies 
the segment number to be terminated. The second argument 
specifies whether or not the reieased segment number is fo be 
reserved. The final argument is a status code. It should be 
noticed that this orimitive may be calted with either a segment 
or clrectory segment number. In the case of terminating a 
directory one constraint is enforced. Since the system requires 
that a known segment*s parent also be known, terminate will nof 
terminate a agirectory with known Inferiors. : 


Since this scheme removes the important function of 
name space management from ring zero we must provide a name space 
manager in the outer ringe Again it is a matter of opinion 
whether name space management shoulda be handied in the supervisor 
or in the user ring. If it resides in the supervisor it cannot be 
clobbered by the user -- neither can it be changed. It is my 
opinion that it should reside in the user ring. Perhaps the 
system coulc also provide a secure address space manager which 
could be used by those users not interested in providing their 
owne I will assume that name space management will be moved to 
the user ering. Regaratess of where it is ptaced all ring zero 
primitives which currently accept pathnames will have to become 
write arounds in some outer rings These write arounds must first 
calf an outer ring procedure which, through appropriate calis to 
the outer ring name space manager and the new ring zero address 
space primitives, translate pathnames into segment numbers. This 
corresponas to the function now performed in ring zero by fing_. 
These segment numbers may then be passed to the new ring zero 
primitives which wili not accept pathnames. 


So far everything seems rosey. This scheme seems’ to 
remove many functions from ering zero and to simolify the ring 
zero interface in the bargaine Where is the hitch? Do we get att 
this for free? Tne answer is, of course, noe I nave glossed over 
one important polnt. In order to decouple directory and segment 
initiatlon we must be abte to sucessfully cloak the physical 
initiation of directories from a process® detection until it has 
established its right to know of fhe existence of the directory. 
As was polntea out eartier, this need for daeception is Intrinsic 
to the hierarchy structure and functionality of the current 
system. While this proposal makes the system’s need to deceive 
the user more obvious, it is not responsible for the required 
deceit. 


I wilt catl a directory detectable If a process has 
established its right to know fthat the directory exists. 
Detectability may be established either by having non-null access 
to the cirectory or by having non-null access to ifs parent or by 
establishing the detectability of an inferior of the directory. 
The reason that non-null access on thre parent of a branch 
estabiisnes cetectability is that either status , modify or 


append permission is sufficient to allow the process to detect if 
the branch in question actualiy exists. It shoula be noted that 
the detectabiltliy of a directory is a function of the  process* 
history and the ring of execution. A directory Is detectabie by 
a process in rings zero through the highest ring in which-it has 
detectably initiated some member of the tree rooted at that 
directory. This highest detectable ring number of a directory Is 
kept In its KSTE. 


We must orevent a process from detecting any difference 
between an Initiated aGirectory which does not exist and an 
initiated existing but undetectable directory. If a process 
could detect a difference in these two cases then It could 
establish the existence of gny postulated path in the hierarchy. 
This woutd constitute a clear violation of security. To 
accomp!ish this means abanconing the current one-to-one anc onto 
mapping which exists between occupied segmenf numbers and known 
segments and directories. We must altow multipie segment numbers 
for the same directory. The reason for this is simpte. Since 
the ACL of a segment completely controts the right to Initiate 
that segment there Is no need to allow a process to initiate a 
segment to which if has no access. This ailows us to hide the 
physical existence of a segment from a process which has no right 
fo know If the segment exists by returning the ambiguous status 
code noinfo in response to an initiate request. This simple 
mechanism fails for directories since we must always aliow a 
process to initiate an existing directory in case it has access 
to some Inferior of that directory. This forces us to return more 
than one segment number for a directory in some cases in order fo 
prevent the process from detecting the existence of physically 
initiated but ftogically undetectable directorles. If initiate_ 
returned the same segment number for two different entries then 
the process could be assured that the corresponding directory 
exists! This requires that we return a new segment number If a 
process reinitiates a directory which is still undetectable with 
a new name. In fact we will even return a new segment number If 
it tries to initiate an undetectable directory with the same name 
twice. If we returned the same segment number then inorder’ for 
directorles which do not physically exist to appear the same to 
the user ring, ring zero would nave to remember the name of every 
phoney directory. This is a needless complication of ring zero. 


This scheme will merrity aliow a process to initlate 
vast trees of directories which do not exist! These directories 
will be indistinguisnable from real undetectabie directories. 
The potential muitiplicity of segment numbers for directories 
Impiies that if we compare two directory pointers and find them 
to be not equal we cannot conclude that the objects pointed to 
are not one and the same. Since processes running oufsicse fhe 
supervisor cannot currently use segment numbers for directories, 
no user code can be effected by this new restrictions. To ailow 
processes to quickly determine if two segment numbers are bound 
to the same object the system should support a function for 


mapping a segment number Into the uniaue identifier of the object 
it is bouna to. Naturalty, this function must return an error if 


the object is not detectabie to the orocesse The system must 
aliso insure that if the user attempts to reference through any 
directory pointer in an outer ring ne witi get Tne appropriate 


access violation whether our not the segment number he used 
corresponded to a reai or phoney directory. 


The action to be taken by ring zero in response to a 
request to initiate a directory depends on four boolean state 
variabies of the target with respect to the accessing processes 
Tnese variables can be encoded as a bit string with the 
interpretation of each bit given pnelow. 


state codes 


state meaning 

1000 target*®s parent is phoney 
0400 target detectable 

0010 target exists 

0001 target already has KSTE 


The possible actions which ring zero can take in response to a 
request to initiate a directory are encoded below. I have 
omitted the case where the target is a tink as this case has 
alreacy been discussed. 


action. coges 
aas assign a segment number to the airectory 
ene refurn a status code indicating tfhat the 
directory does not exist 
enc return a status code indicating that the 


directory either does not exist or that the 
process has not establisned its right to know 
that It exists 


rps return segment number and a status code 
indicating that the directory was atready 

| known | 

sd update highest caetectabtie ring ficela of this 


KSTE and Its superlor KSTEs to fhe maximum of 
their current vaiue ana the ring of execution 
sdz set nighest detectable ring field to zero 


This encoding aliows us to compactly characterize the functioning 
of initiate_ In the folftowing tabiee Entries in the state cotfumn 
encode a possible state. Entries in the action column encode’ the 
actions to be taken given the state represented in the state 
column. 


action of initiste_ 

state action 

00-- @as,sdz,end 
010- ene 

0110 aasesa 

0111 rps 

{coe 2as4sdz,end 


Two possible objections I can see to this scheme are 
That it can potentially waste segment numbers and it requires 
inspecting the oarent*s ACL. A close examination of the 
preceeding charf indicates that there are only two ways fo assign 


a segment number which is not directiy connected fo a clrectory. 
The first way is to reinitiate an undetectabie directory. The 
second is to Initiate a phoney directory. Neither of these 
operations should occur in normat operation. They could, however, 
arise in an attempt to use a misspeiiec pathname. To eradicate 
this problem the outer ring variant of find. could terminate 
those cirectories which mignt be phoney If the terminai segment 
could not be initiated. Tnis would prevent a habitual misspeller 
from cluttering up his address space. It seems that with this 
addition a process must go out of Ifs way inorder to clutter up 
its address space. If that is what it wants finet Even if a 
process wastes ail its segment numbers It can recover by 
termineting no tonger needed segment numbers. The apparent 
inefficency of inspecting the ACL of the parent of a branch 
during initiation of that branch is not serious since It Is 
normally not required. Only when a process has null access to a 
branch and has not previous.y establisned detectability for that 
branch is It necessary to inspecf the ACL of the parent. 


In the ota KST scheme, the names stored with each KSTE 
provided a means of telling what rings stil! had the associated 
segment or directory initiatea. Since these names will no fonger 
be kept in the KST some new mechanism must be invented to supply 
this information. This is easily accomptisnhed by adding an eight 
bit fiela, calted rings, to each «STE. If the i th bit 9 
origined) in this fietd is on then the corresponding ring has the 
segment or directory initiated. This attows ring zero to detect 
when & segment or cirectory may be pohysicalty terminatec, thereby 
preventing one ring from terminating a segment or directory that 
is belng used by another ring. 


It shoulda be carefully noted that the termination 
primitive terminates a segment number. Only if the tast segment 
number for a alrectory is being terminated and its inferior count 
is zero will it be physically terminated! We can use the same 
method to describe the action of the terminate primitive as was 
usec to aescribe the actlon of the initiate primitive. 
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state codes 


state meaning 
4006 KSTE has inferlors known 
C10 KSTE known in other rings 
001 reserve requested 
action. coges 
rr reset this ring"s known bit 
tf thread KSTE onto free chain 
tr threac KSTE onto reservea chain 


action of terminate orimitive 


state action 
000 rr,tf 
O01 re,tr 
-i- rr 

=> ore 


In summary, this proposal calls for the complete 
removal of name space management from ring zero. As a resuit fhe 
concepts of pathname and file system links also depart ring zero. 
In the process of removing name space management from ring zero; 
I nave reorganized and improved the ring zero interface and 
address space manager. The KST nas been simplified and contains 
oniy two components: a KSTE array, anda UID hash table. The 
contents of each KSTE and their major uses are summarizes below. 


KSTE_fleid Use 

forward pointer, 

backward pointer Used to thread KSTE onto (free or 
hash ciass tist as required. 


unique identifier Unchanged (a phoney directory will 
have a uld = 0). 


inferior count Unchanged, 


entry pointer A packed pointer to the directory 
entry of this pranch.e 


directory swifch Unchanged. 


transparent modification switch, 
transparent usage switch Unchanged. 


rings An elght bit fletd containing one 
bit per fringe. Knenever ring i has 
this segment number initiated then 
bit i of this fielta is on. 


highest detectable ring ' A number which specifies the 
highest ring in which this process 


has estabiished its right to know 
of the existence of this directory. 


Tne proposed ring zero segment number manager interface Is as 
foliows. . 


initiate. (dirsegno,enamesdirsworsw,linkssegno,code) 


dirsegno segment number of the parent (¢ input) 


ename entry name of target(input) 

dirsw directory switchlinput) 

rsw reserved segment switch(input) 

link link (output) . 

segno segment number of target(if rsw then Input } 
coae status codeloutput) 


terminate_(segnosrsw,code) 


segno segment number to be tTerminated(input) 
rsw see above 
code see above 


To help cflarify the ideas presenteca in this proposai 
let us consider the following senario in which a process trys to 
Initlate the segment >a>b>c>d>er-f in ring four. We will assume 
that directory e and segment f do not exist and that the process 
has no opermission on a, 6b Or dy and append permission onc tin 
rings zero through four. To simpilfy matters we will ignore the 
existence of the outer ring name space manager and we will assume 
that we are operating in a virgin environment. What follows Is 
how the outer ring fino_ would proceed in this case. 


step 0 call initiate (0o"%"51,0,linkssegno_of_root,code) 


The root cirectory will be initiated, its detectbie 
field in the KSTE will be set to four, and a status 
code of zero wil! be returned. 


step 1 cali 
initlate_(segno_of_root,”"a"sisdesilnkssegno_of_a,code) 


The Girectory will be initiated, its detectable fieid 
in the KSTE will be set to four, and a status code of 
zero wltti be returned. 


step 2 call initiate_(segno_of_ae"*b"sis0,tinkssegno_of_b,code) 


The directory will be initlated , its detectable fietd 
in the KSTE wili be set to zero, and the status code 
noinfo wilt be returned. 


step 3 call initiate _(segno_of_b,*c"»1,0s4inkssegno_of_c,code) 


Tne directory witlt be initiated, its detectable field 
in the KSTE witli be set to four, and a zero status code 
will be returned. In addition this initiation 
establishes the process" right to know of the existence 
of superior airectoriles at feast in rings zero through 
four. This is reflected, in this case, by setting the 
detectable field in the KSTE of >a>b to four. 


step 4 call initlate_(segno_of_cs"“d"sis0elinkssegno_of_d,code) 


The directory d wilt be Initiated, its detectable fleid 
in the KSTE will be set to four, and a zero status code 
wifl be returned. 


step 5 call inittate_(segno_of_d,"e",150,linkssegno_of_e,code) 


The non existant directory e will be assigned a KSTE 
which will be marked as ohoney and the status code 
noinfo will be returned. 


step 6 call initiate _(segno_of_e,"f",0.70,link,segno_of_f,code) 


No KSTE witli be assigned and the status code noinfo 
will be returned. 


step 7 catl ferminate_(segno_of_¢€.0,code) 


The segment number assigned to e will be released on 
the grounds that e may reatty not exist. 


The address space manager proposed in thls MTB has been 
written and is many times simpler and smafter than the current 
ring zero adaress space managere In some modules the reduction 
in size is on the order of a factor of ten! In addition, a 
version of hardcore which preserves the current ring zero 
Interface is being debuggea which is built on this new adgaress 
space manager. 
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APPENDIX A 


The malin data base for the current ring zero address 
and name space manager is Tne Known Segment Jabdie.e The KST is a 
per-process, ring zero segment. Logically it contains four items. 
First, it contains an array of KST Entries. KSTEs are indexed by 
segment number and contain all per-process information necessary 
for the proper care and feeding of the segment or directory 
associated with the indexing segment number. Second, it contains 
a hash coded mapping from the space of Unique [Pentiflers onto 
the space of segment numbers, or equivalently the space of KSTEs. 
This mapping provides the means of tocating the KSTE of an 
already initiated segment should it subsequently be initlated by 
a aifferent name. Third, it contains a hash coded mapping from 
the space of names onto the space of segment numbers. This 
association is mainty of use to the dynamic Jinking mechanism. 
Forth, it provides a repository for perering search rules. This 
later KST function will pe considered no further as the user-ring 
dynamic tinker removes this information from the KST. The current 
contents of a. KSTE and their major usages are given in the 
following table. 


KSTE_fieig 


forward pointer, 
backward pointer 


unlque identifier 


name pointer 


inferior count 


parent segment number 


offset of branch 


airectory switch 


transparent modifications 
transparent usage switch 


Use 


Used to chain the KSTE onto a list 
af free or raserved KSTEs as 
required. 


Used to vailaate UID hash searches 
and to properly identify the 
corresponding branch after an 
on-line salvage. 


Used to chain together a ltist of 
the reference names associated with 
this segment or directory and the 
rings in which they are known. 


Used to prevent a directory § (from 
being terminated while it has known 
SONS. If this were not done 
segment faulfs would failt 


Used at segment fautt time to 
locate this obranch*s parent. If 
aiso is used to ftransiate segment 
numbers Into pathnames. 


Used to locate the branch within 
the parent directory. 


Used to special! case access setting 
for directories at segment fault 
time. 


Used to control whether this 
process*® usage and/or modification 
of this segment or alrectory should 
be transparent to the system. 
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